由于测试环境上面使用的zabbix服务器配置比较低,经常会遇到性能瓶颈(主要是数据库和磁盘I/O等),于是倒逼我使用了一些方式来缓解这些问题。
主要是以前使用的那个备份数据库的脚本是对zabbix数据库进行全备的,使用的又是mysql自带的工具mysqldump,当数据量大了之后进行全备所花的时间比较长,这样将会造成数据库的锁读。。。从而使zabbix服务以为mysql死掉了,产生一大堆的报警。
后来发现原来造成数据库数据量大量增加的是zabbix数据库中的一些存储数据的大表导致的。于是备份数据库的时候可以选择跳过这些表进行备份,这样,将大大减少数据库备份所花的时间(PS:之前备份数据库所花时间在十分钟左右,现在跳过大表备份,所花时间在1S左右就能备份完,大大缩短了备份数据库时间)。
下面就贴出某位大神写的专门为zabbix数据库做备份以及恢复的脚本:
|
|
该脚本源出处在这https://github.com/itnihao/zabbix-book/blob/master/03-chapter/Zabbix_MySQLdump_per_table_v2.sh
这是在大神的脚本上做了修改之后形成的适合我自己备份的脚本,各位也可以自行修改成适合自己的备份脚本。这个脚本实现的效果上面已经说了,之前做全备的时候差不多有4G左右的数据量,现在只备份配置文件数据量只有不到10M,果断大大节省时间以及空间呀。
不过这样的话将无法保证数据的备份,目前考虑使用xtradbbackup对数据进行增量备份,目前还未实现,留待过两天做吧。
好了,关于数据库备份的事情搞了,然后还需要对大数据量的表进行表分区,参考了zabbix官网的一篇文章https://www.zabbix.org/wiki/Docs/howto/mysql_partition 各位有兴趣的话可以去看看,我这里将其总结在了一起,更加方便一点。
表分区可以对大数据量的表进行物理上的拆分成多个文件,但是逻辑上来看,还是一张表,对应用程序是透明的。另外,将这一张大表拆分成很多小表的话将使得数据查询速度能够更快。还可以随时删除旧的数据分区,删除过期数据。这种方式适用于大数据量的表,但是查询量比较少的应用场景。如果是大数据量的表,又有大量查询的话建议还是进行分库分表操作。
首先,登录数据库(PS:这个就不演示了)
然后登陆到zabbix库中修改两张表的结构:
|
|
修改完之后再按照官网上的过程创建四个存储过程:
|
|
|
|
|
|
|
|
上面四个存储过程执行后将可以使用
|
|
命令对想要分区的表进行表分区了。其中的参数我这里解释一下。
这是举例:
|
|
- zabbix_db_name:库名
- table_name:表名
- days_to_keep_data:保存多少天的数据
- hourly_interval:每隔多久生成一个分区
- num_future_intervals_to_create:本次一共生成多少个分区
这个例子就是history_uint表最多保存31天的数据,每隔24小时生成一个分区,这次一共生成14个分区
这里可以将上面四个存储过程保存为一个文件,导入到数据库中,文件我稍后将会放在附件中,这里使用的命令是:
|
|
然后可以将CALL统一调用也做成一个文件,统一调用的内容如下:
|
|
也将该文件导入到数据库中,使用命令:
|
|
好了,到了这里之后就可以使用如下命令执行表分区了:
|
|
看到如下结果证明所有7张表都进行了表分区,也可以在Mysql的数data目录下看到新生成的表分区文件。(PS:注意,最好是清空history_uint表的数据之后再执行上面这条命令,否则因为这张表数据量太大,转换时间将会好长,清空表中数据的命令为: truncate table history_uint;)
好了,这样可以进行表分区了。
将上面这条命令写入到计划任务中如下:
|
|
每天晚上的1点01执行一次。还有之前写的备份数据库的脚本也需要执行计划任务每天的凌晨0点01执行备份:
|
|
这样就大功告成了,之后再体验一下zabbix的web页面看是不是感觉比以前快了?